• (refuse. <agent_id> <service_name> <conversationJd> 
<messagejcl>) 

failure The failure interface. 

• (failure <agentjd> <service_name> <conversationJd> 
<messagejd>) 

Inform The inform interface. 

• (infonm <agentjd> <sefvice_name> <conversationJd> <messagejd>) 

Agent Archi^et^qr'^ 

There follows a description of the design of the agenfs internal negotiation 
deliberation mechanisms. Each agent in the scenario is assumed to be 
architecturally equivalent. Sections below are the detailed description of ttie 
components of this architecture. 

The Negotiation Reasnnim Mo^H 
The reasoning model detemiines ttie agents behaviour in a given negotiation 
context. It is responsible for 

• initiating negotiation to obtain a desired service 

• responding to proposals from other agents 

• detemiining when proposals should be accepted or rejected 

• and determining when counter-offers should be made and what these 
counter offers should be. 

Negotiation has three reasoning components (see [1] for a fomial specification) 
which are supported by infonnation maintained in the agent models and the agenfs 
working memory. 
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Service Deployment 

The service architecture and agent-based implementation described enables 
direct flexibility in how the agents used to compose the Reverse Auction application 
described can be deployed. This has the effect that the agents could all be hosted 
by an ASH (Application Service Host) in a single or set of multiple servers or simply 
the intermediary agent could be hosted by an ASH leaving the owners of the buyer 
and seller agents to host their respective agent. 

The forni of interaction between the agents will remain constant inrespective 
of how distributed the agents are once deployed however, unless IP VPNs with 
guaranteed QoS (or alternative IP technology that enables guaranteed QoS such as 
MPLS) are used to connect the distributed agents there will be a non-deterministic 
delay in the delivery of bids and counter bids between the agents which will impact 
the results of the auction and may limit the competitiveness of a given remote agent 
as the order and timing of the bids is a key factor in the functionality of the auction 
process. 

Reverse Auction Protocols 

The technology described above enables a mechanism for generating bids 
based on configuration data and counter bids based on received bids in addition to 
the configuration data. The reverse auction concept describes the concept of 
combining potentially many peer buyers and sellers in a single auction (negotiation) 
such that the augmented negotiation power of the buyers and/or sellers can be used 
to derive gains generally attributed to bulk purchases in the traditional economic 
model. 

The Interaction Use Cases discussed below represent the groups of agents 
that will interact with each other. The communications layer of the agent platform 
supports the exchange of messages between the agents in the fomis illustrated in 
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User access to this advanced eCommerce which has a potentially globally 
distributed (made possible primarily by the Internet) set of participants (buyers, 
sellers, and intermediaries) will be possible, seamlessly from variety of devices 
ranging from next generation mobile phones. PDAs and Internet access devices via 
the use of the agent platform described iri our previous Agent Enabling Technology 
patent application. In additon the basic distribution platfomi features have also 
been developed to enable user access via WAP enabled and/or HTML enabled 
GUIs. 



